United States Patent [19] 

Blakley, III et al. 



[54] RETRIEVING PLAIN-TEXT PASSWORDS 
FROM A MAIN REGISTRY BY A 
PLURALITY OF FOREIGN REGISTRIES 

[75] Inventors: George Robert Blakley, III; Ivan 
Matthew Milman; Wayne Dube 
Sigler, all of Austin, Tex. 

[73] Assignee: Internationa! Business Machines 
^Corporation, Armonk, N.Y 

[21] Appl. No.: 557,754 

[22] Filed: Nov. 13, 1995 

[51] Int. CI. 6 H04K 1/00; H04L 9/00 

[52] U.S. CI 395/188.01; 380/21; 395/186; 

395/187.01 

[58] Field of Search 395/188.01,187.01, 

395/200.01, 500, 609; 340/825.34; 380/25, 

23 

[56] References Cited 

U.S. PATENT DOCUMENTS 



4,386,233 5/1983 Smid et al 178/22.08 

4,694,492 9/1987 Wirstrom ct al 380/23 

5,241,594 8/1993 Kung 380/4 

5,241,599 8/1993 Bellovin et al 380/21 

5,276,869 1/1994 Forrest et al 395/600 



111 Hill III Ml lAl HI II 111 Ul III ■ II 

US005862323A 



[ii] Patent Number: 5,862,323 
[45] Date of Patent: Jan. 19, 1999 



5,329,619 7/1994 Page et al 395/200.01 

5,335,281 8/1994 Tugenberg et al 380/48 

5,351,295 9/1994 Perlman el al 380/23 

5,369,707 11/1994 Follendore, ID 380/25 

5,495,607 2/1996 Pisello et al 395/600 



Primary Examiner — Ly Hua 

Attorney, Agent, or Firm— Jeffrey S. LaBaw; Brian F. 
Russell; Andrew J. Dillon 

[57] ABSTRACT 

A network system server that provides password synchro- 
nization between a main data store and a plurality of 
secondary data stores is disclosed. The network system 
server includes a security server, which is coupled to the 
main data store, a plurality of clients, which is coupled to the 
security server for accessing the main data store wherein 
each client maintains a unique, modifiable password, a 
password synchronization server, which is coupled to secu- 
rity server and the plurality of secondary data stores, and a 
password repository, which is coupled to the password 
synchronization server, that stores the passwords. One of the 
secondary data stores can retrieve the passwords via the 
password synchronization server so that each client is able 
to maintain a single, unique password among the plurality of 
secondary data stores. Password retrieval is instigated by at 
least one of the plurality of secondary data stores regardless 
of the current password status of the secondary data stores. 
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RETRIEVING PLAIN-TEXT PASSWORDS 

FROM A MAIN REGISTRY BY A 
PLURALITY OF FOREIGN REGISTRIES 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

The present application is related to U.S. patent applica- 
tion Ser. No. 08/557,755 Attorney Docket No. AT9-95-065, 
entitled "Propagating Plain-Text Passwords from a Main 
Registry to a Plurality of Foreign Registries," and U.S. 
patent application Sen No. 08/556,724 Attorney Docket No. 
AT9-95-067, entitled "Configurable Password Integrity 
Servers for Use in a Shared Resource Environment," all filed 
of even date herewith by the inventors hereof and assigned 
to the assignee herein, and incorporated by reference herein. 

BACKGROUND OF THE INVENTION 

1. Technical Field 

This invention relates generally to data processing sys- 
tems and, more particularly, to resource sharing among data 
processing systems with password synchronization. More 
specifically still, the present invention relates to providing 
password synchronization between a general repository to a 
plurality of local resources for each user within a client/ 
server system. 

2. Related Prior Art 

Computer networks are well known in the arts and 
continue to grow in both size and complexity. This growth 
is fueled by more computers being connected to networks 
and connecting networks to other networks. This is done in 
order to enable computers to work together efficiently, to 
simplify sharing resources such as files, applications, 
printers, and even special computers. 

Unfortunately, many networks contain computers from 
different manufacturers, which complicates the task of get- 
ting computers to work together efficiently. Computers in 
such "multi- vendor" networks are usually difficult to operate 
together because they do not use common data formats or 
common security mechanisms. The lack of a common 
network naming scheme also limits the degree to which 
computers can share information. 

In order to overcome many of the above problems, the 
Open System Foundations ("OSF") Group has been formed 
that has developed the Distributed Computing Environment 
("DCE") that transforms a group of networked computers 
into a single, coherent computing engine. DCE masks dif- 
ferences among different kinds of computers, thereby 
enabling users to develop and execute distributed applica- 
tions that can tap into a network's latent power, using 
widespread resources such as storage devices, CPU's, and 
memory. Because distributed parts of these applications can 
execute concurrently, they can be much more powerful than 
single processor applications that must act on data sequen- 
tially. 

Unfortunately, even distributed computing environments 
have their own problems such as how to protect data that 
must be shared among multiple users. Additionally, events 
must be synchronized between separate computers and 
computers with differing data formats and file-naming 
schemes must be allowed to work cooperatively one with 
another. DCE overcomes many of these problems and pro- 
vide solutions to these vexing issues. 

DCE is well known in the industry, an example of such is 
shown in FIG. 1. FIG. 1 is a block diagram of DCE 
application programming interface 1 that provides for a 
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2 

DCE file service 3. DCE is a layer of software that masks 
differences between various kinds of hosts. As a layer, it sits 
on top of a host operating system 5 and networking services 
for network transport 7. The DCE distributed services, 

5 which include security 9, directory 11, and time 13, remote 
procedure call ("RPC") 15 and thread services 17. RPC 15 
and threads 17 are base DCE services that are available on 
every system on which DCE is installed. FIG. 1 further 
shows how the DCE file service is similar to an application 

10 that uses the underlying DCE services for distribution. DCE 
directory service further consists of a cell directory service 
19 ("CDS") and a global directory service ("GDS") 21, 
which programs use by calling the directory service 
("XDS") application programming interface ("API"). 

15 Typically, each user must first prove bis or her identity by 
using a secret password to log onto the local host. The local 
host uses the password, which is known only to the user and 
the local host, as proof that the user is who he or she claims 
to be. Once the user logs onto the local host, the host 

20 resources are usually protected further by means of permis- 
sions or privileges associated with each file. The permissions 
regulate whether a user can read, write or execute that file. 
The number of users on a single local host is typically small 
enough so that the host alone can manage all of the pass- 

25 words and permission functions. 

A distributed computing environment, on the other hand, 
might support thousands of users accessing files on any of 
hundreds or thousands of local hosts in the environment. 
Because it is impractical to maintain every DCE user's 

30 security information on every host in the environment, DCE 
serves security information from a centralized database. 
This database, along with a distributed set of daemons and 
libraries, compose the DCE security service. 

3S When servers enforce security, each client must provide 
its user's identity and access rights. These are provided on 
the first RPC call, and sometimes in highly secure 
environments, on every RPC call. Because access to every 
DCE resource — directories, files, printers, and so on — is 

^ controlled by a server, the server's demands for authentica- 
tion and authorization require comprehensive network secu- 
rity. This applies to DCE servers, such as those of the CDS, 
as well as user application servers. The server verifies the 
clients' authenticity and authorization before allowing 

45 access to the resource. 

Typically, security service functions are built into appli- 
cations. This means that the clients call local security 
routines to request authentication information from a secu- 
rity server and pass it to other servers. Servers also call 

so security routines to verify authentication information and 
enforce authorization. Authentication is the ability to prove 
one's identity to someone else. Authorization is the ability to 
regulate access based on one's identity. Passwords are used 
to ensure authenticity and then to gain authorization. 

55 In DCE, the security service, which is also known as a 
registry, serves as a single source of security and manages 
information about users, groups, and the like. This gives a 
company a single place to define and manage users. One 
limitation to this approach is the propagation of passwords. 

60 Most registries only store an encrypted version of the user's 
password. Often, though, the encryption mechanism at each 
registry is different than any of the other registries, espe- 
cially in a system where dissimilar registries from different 
vendors are being used. Thus, a password encrypted by the 

65 DCE registry may be unusable by another registry manu- 
factured by someone other than the vendor of the DCE main 
registry. Accordingly, it would be beneficial to be able to 
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propagate the plain-text password securely from the DCE 
registry to registries that synchronize with the DCE registry 
so that other registries can then encrypt the password in their 
own formal. This would allow a user to avoid having 
multiple passwords, typically one for security registry, and 
avoid the necessity of updating these passwords manually in 
each registry to insure they are consistent across all security 
registries. 

Further, the DCE registry does not provide a way of 
populating a new non-DCE or foreign registry that wishes to 
populate its database with users and passwords from the 
DCE registry. This is because the DCE itself typically only 
stores encrypted passwords and the new registry cannot 
obtain the plain-text passwords it needs to populate its 
database until an update occurs to a given user's password. 
Accordingly, it would be beneficial to provide a system that 
overcomes the prior problem of not being able to propagate 
passwords to new registries until an update to a given user's 
password has occurred. 

SUMMARY OF THE INVENTION 

The primary objective of the present invention is to 
provide a password synchronization function that allows 
foreign registries to maintain local password synchroniza- 
tion with those maintained by a security server in the main 
registry. The function allows any number of foreign regis- 
tries to automatically receive passwords for system accounts 
of interest to them whenever those system accounts are 
defined or undergo a password change, and to acquire the 
password for these accounts on demand. Foreign registries 
must use the system services in order to receive such 
password updates that allow them to maintain password 
synchronization. The main registry acts as a central reposi- 
tory for the information controlling which password changes 
are appropriate for propagation to specific foreign registries. 

In one embodiment, a network system server that pro- 
vides password synchronization between a main data store 
and a plurality of secondary data stores is disclosed. The 
network system server includes a security server, which is 
coupled to the main data store, a plurality of clients, which 
are coupled to the security server for accessing the main data 
store wherein each client maintains a unique, modifiable 
password, a password synchronization server, which is 
coupled to security server and the plurality of secondary data 
stores, and a password repository, which is coupled to the 
password synchronization server, that stores the passwords. 
Any one of the secondary data stores can retrieve the 
passwords via the password synchronization server so that 
each client is able to maintain a single, unique password 
among the plurality of secondary data stores. Password 
retrieval is instigated by at least one of the plurality of 
secondary data stores regardless of the current password 
status of the local data stores. 

The main data store further maintains an information 
account for each of the plurality of clients that includes a 
user's password, an information account for the password 
synchronization server that binds each of the plurality of 
secondary data stores with each of the plurality of clients, 
and an information account for each of the secondary data 
stores. 

The security server provides a clear-text password to the 
password synchronization server for propagating to each of 
the plurality of secondary data stores. Further, the security 
server includes means for encrypting the clear-text password 
for storage in the information account. 

A temporary memory and retry data store is also coupled 
to the password synchronization server. The temporary 
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memory and retry data store contains information supporting 
a retrieve retry that allows the password synchronization 
server to perform a retrieve retry in the event of a temporary 
foreign registry or password synchronization server outage. 
5 The .above as well as additional objects, features, and 
advantages of the present invention will become apparent in 
the following detailed written description. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 

The novel features believed characteristic of the invention 
are set forth in the appended claims. The invention itself, 
however, as well as a preferred mode of use, further objec- 
tives and advantages thereof, will best be understood by 
15 reference to the following detailed description of an illus- 
trative embodiment when read in conjunction with the 
accompanying drawings, wherein: 

FIG. 1 is a block diagram of a prior art DCE security 
server; 

20 FIG. 2 depicts a pictorial representation of a distributed 
data processing system according to the present invention; 

FIGS. 3A-3D illustrate an exemplary DCE synchroniza- 
tion and security system for use in the distributed processing 
system of FIG. 2; 

25 

FIG. 4 illustrates the password synchronization retrieve 
function; 

FIG. 5 illustrates the password synchronization propaga- 
tion function; 

30 FIG. 6 depicts the steps that extend password synchroni- 
zation to support password strength servers that may be 
customer-tailored according to a user's particular needs; 

FIG. 7 depicts a flow chart of user password processing 
from the security server; 

35 FIG. 8 illustrates the password synchronization server 
propagation queue thread; and 

FIG, 9 depicts a flow chart of the password synchroniza- 
tion server retry queue thread according to the present 
invention. 

40 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENT 

With reference now to the figures, and in particular with 
45 reference to FIG. 2, there is depicted a pictorial represen- 
tation of a distributed data processing system 8 or distributed 
computing environment (DCE) system, which may be uti- 
lized to implement the method and system of the present 
invention. As may be seen, distributed data processing 
50 system 8 may include a plurality of local resource networks, 
such as Local Area Networks (LAN) 10 and 32, each of 
which preferably includes a plurality of individual comput- 
ers 12 and 30, respectively. Of course, those skilled in the art 
will appreciate that a plurality of Intelligent Work Stations 
55 (IWS) coupled to a host processor may be utilized for each 
such network. 

As is common in such data processing systems, each 
individual computer may be coupled to a storage device 14 
and/or a printer/output device 16. One or more such storage 

60 devices 14 may be utilized, in accordance with the method 
of the present invention, to store the various data objects or 
documents which may be periodically accessed and pro- 
cessed by a user within distributed data processing system 8, 
in accordance with the method and system of the present 

65 invention. In a manner well known in the prior art, each such 
data processing procedure or document may be stored within 
a storage device 14 which is associated with a Resource 
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Manager or Library Service, which is responsible for main- across the non-common remote servers from their particular 

taining and updating all resource objects associated there- local host server, 

with. The DCE system of FIG. 2 includes a mechanism for an 

Still referring to FIG. 2, it may be seen that distributed enterprise to install a password strength checking server. 

data processing system 8 may also include multiple main- * Whenever the DCE registry receives a request to update a 

frame computers, such as mainframe computer 18, which password which includes the user account creation, the 

may be preferably coupled to Local Area Network (LAN) 10 ^7 <* ecks tc \f e * Pf>wo*d checking is enabled. If so, 

by means of communications link 22. Mainframe computer 11 sends / he record > wh i ch m f^ des the u f r ^me and the 

18 may also be coupled to a storage device 20 which may ^ P ^ d P f assword ' t0 the P assword f ren S th se ™ 
' . < c T ,f KT , i^TAXT\*«m The data is then forwarded in such a way that it is encrypted 

serve as remote storage for Local Area Network (LAN) 10. 10 4 , * i * * n Ai_ r^i-j nnA\. . 

a i a kt ^ i^taxa^-i . / . 4 over the network, typically using one of the D CE s R PC, but 

A second Local Area Network (LAN) 32 may be coupled to i • « . j u j * j i_ * L . iL 

w i » KT . wr axt\ m • • *■ the plain-text password can be decrypted by the strength 

Local Area Network (LAN) 10 via communications con- tt. * *u * ■ n t. i , L j 

, ■ ii*A* server. The strength server typically checks the password 

troller 26 and communications link 34 to a gateway server t u„ !L*„ u;, * u *~ * ■ ta *u * 

- D „ . - 0 . r L1 . j. Tj , . against the rules determined by the customer to insure that 

28. Gateway server 28 is preferably an individual computer »Cl • „^ „ ' . c . i n 

i . it »w i c» /i«7o\ u- u * i- * T i k tne password is not easily guessed. Such rules are well 

or Intelligent Work Station (IWS) which serves to link Local 15 i • . , ' , f , ( tu , -„ . 4 

Area Network fLAN) 32 to Local Area Network CLAN) 10 in ^ artS and are left l ° the skllled artlSan t0 

Area weiwoiK (LAiNj ^ to Local Area Network (LAINJ 1U. i mp i e ment. The password strength server then replies back 

As discussed above with respect to Local Area Network t0 the registry service, informing it that the change is either 

(LAN) 32 and Local Area Network (LAN) 10, a plurality of acceptable or not acceptable. An example of a DCE syn- 

data processing procedures or documents may be stored chronization and security system for use in the distributed 

within storage device 20 and controlled by mainframe processing system of FIG. 2 is illustrated in FIGS. 3A-3D. 

computer 18, as Resource Manager or Library Service for p or pr0 p agation of plain-text passwords to other security 

the data processing procedures and documents thus stored. registries that wish to be synchronized with DCE, a novel 

Of course, those skilled in the art will appreciate that password synchronization server is now provided that 

mainframe computer 18 may be located a great geographical ^ securely propagates plain-text passwords to these registries, 

distance from Local Area Network (LAN) 10 and similarly A model of the DCE system with appropriate DCE registry 

Local Area Network (LAN) 10 may be located a substantial an d the novel password synchronization server is illustrated 

distance from Local Area Network (LAN) 32. That is, Local in the block diagram of FIG. 3A. In FIG. 3A, DCE registry 

Area Network (LAN) 32 may be located in California while 102 is coupled to a DCE security server 104, which in turn 

Local Area Network (LAN) 10 may be located within Texas 3Q is coupled to a password synchronization server 106 and 

and mainframe computer 18 may be located in New York. various foreign registry servers X-Z 108. Each foreign 

As will be appreciated upon reference to the foregoing, it registry server 108 typically comprises a local server and a 

is often desirable for users within one portion of distributed secondary data store used to maintain local information such 

data processing network 8 to access a data object or docu- as local passwords for one. 

ment stored in another portion of data processing network 8. 35 Password synchronization server 106 is further coupled to 

In order to maintain a semblance of order within the docu- various local password strength servers X-Z 110 as well as 

ments stored within data processing network 8 it is often to a password repository 112, which includes user names and 

desirable to implement a one-way access control program. associated passwords. DCE security server 104 is further 

This is generally accomplished by listing those users autho- coupled to each client W-Y 114. 

rized to access each individual data object or document, 40 Within DCE registry 102 there is aD account for each 

along with the level of authority that each user may enjoy client W-Y. (in FIG. 3A only client Y is illustrated), but all 

with regard to a document within a Resource Manager or clients are provided for in the DCE registry. Associated with 

Library Service. In this manner, the data processing proce- each client Y are various ERAs such as password manage- 

dures and documents may be accessed by enrolled users ment binding, which allows the security server to locate the 

within distributed data processing system 8 and periodically 45 password synchronization server or password strength 

"locked" to prevent access by other users. It is the system server for this client; foreign registry, which enumerates the 

administrator who typically controls access and performs foreign registries authorized to receive password propaga- 

modifications for security. tions for this client; plain-text password, which allows a 

Open Systems Foundation (OSF) Distributed Computing foreign registry to locate and request the plain- text password 

Environment (DCE) 1.1 provides a facility called Extended 50 from the password synchronization server; and password 

Registry Attributes (ERA) that allows non-DCE registries to strength, which identifies the password strength server for 

store attributes unique to these registries within the DCE this client. Additionally, accounts for each foreign registry 

Registry. This allows the DCE Registry service to be used as 108 are also maintained within DCE registry 102. Although 

a centralized repository for security information related to the example in FIG. 3Aonly depicts the account for foreign 

all users in the enterprise, whether or not the registries are 55 registry Z, all foreign registries from X-Z, or any number 

DCE registries. Although the embodiment presented below desired by. a particular customer, are provided for in DCE 

is described as a system that operates as a DCE system, it registry 102. The account for each foreign registry includes 

will be readily apparent to those skilled in the art that the the foreign registry password propagation binding ERA, 

present invention is not limited to a DCE implementation which allows the password synchronization server to locate 

only, but is extendible to all distributed LANs that use a 60 the foreign registry for purposes of password propagation, 

main or global system server that can accommodate foreign Accounts for each password strength server 110 are also 

or remote registry servers. Accordingly, although DCE is provided. Again, only one password strength server 110 is 

used in its properly accepted definition, that definition is illustrated in FIG. 3A, but accounts for each of the password 

extended in this disclosure to mean extended LANs or strength servers X-Z may be included. Each such account 

WANs having a plurality of non-common remote servers 65 contains the secondary password management binding ERA, 

attached to a main system server for allowing a user or which is used by the password synchronization server to 

plurality of users to maintain password synchronization locate the password strength server for a given client. 
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Lastly, the DCE registry further includes an account for 
the password synchronization server 106 and comprises 
three ERAs. These three ERA's include password propaga- 
tion enable, password propagation retry interval, and foreign 
registry. Each of these ERAs will be described in greater 
detail below. 

Synchronization of passwords between the DCE registry 
and a foreign registry requires a solution that satisfies two 
requirements: 

1) Provides a way for a foreign registry that has been 
configured into the network after the DCE registry has 
been populated with user definitions to acquire, on 
request, the passwords for selected users without the 
need to wait for those points in time at which the 
passwords will (may) be changed. 

Meeting this requirement allows the foreign registry to 
generate initial user/password definitions in its local registry. 
This function is herein subsequently referred to as the 
"password synchronization puir function. 

2) Provides a way for a foreign registry to receive 
automatically password changes for selected users 
when these passwords are changed in the DCE registry. 

This function is herein subsequently referred to as the 
"password synchronization push" function. 

FIG. 4 illustrates the password synchronization pull 
function, a set of operations that service a foreign registry 
wishing to populate its own database with users and pass- 
words from the DCE registry. Without this function, and 
because the DCE registry itself only stores encrypted 
passwords, the new registry cannot obtain the plain-text 
passwords it needs to populate its database until an update 
occurs to a given user's password and this update is propa- 
gated to the new registry via the password synchronization 
push function described in FIG. 5. The flow diagram of FIG. 
4 depicts a solution to this problem in that it modifies the 
password synchronization server of FIG. 3A, which is 
represented in FIG. 3B with respect to the elements used in 
the retrieval operation, so as to store user names and 
plain-text passwords securely and to respond to requests for 
their retrieval. Support for this function requires the pres- 
ence of a new data item for each affected user in the DCE 
registry. This data item is titled PLAINTEXT_PASSWORD 
and is a DCE extended registry attribute called, in DCE 
terminology, a "query trigger." Foreign registry attempts to 
read this ERA result in a query to the password synchroni- 
zation server that subsequently returns the password for that 
user. It is noted that although DCE uses ERAs to associate 
password information with a user's account, any mechanism 
or security server that associates the user's password with 
the user's account can also be used. For example, the 
security server may have fields or use pointers for associa- 
tion. 

A description of the operations represented in FIG. 4 
follows. In block 410, a password update request is issued to 
DCE security server 104. In this case, client W requests 
account creation or password change for client W's account. 
In Block 412, DCE security server 104 upon the request 
retrieves the required routing information contained in the 
password management binding ERA associated with client 
Y's account and uses it to locate the password synchroni- 
zation server 106. Next, in block 414, the security server 104 
sends a clear text password and client Y identity to the 
password synchronization server 106. Afterwards, in block 
416, password synchronization server 106 encrypts this 
information and stores it in its password repository 112. 
Afterwards, in block 418, the password synchronization 
server 106 returns a "complete" message to the security 
server 104. 
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The security server 104, in block 420 encrypts the pass- 
word and stores it in the client W account within DCE 
registry 102. Afterwards, the security server returns a "suc- 
cess" message to client W (block 422). 

5 At any time following the completion of the above steps, 
foreign registry Z 108 can request a copy of client W's 
password by requesting the security server to retrieve the 
value of the plain-text password ERA associated with client 
W's account as shown in block 424. In block 426, the 

10 security server retrieves the plain-text password ERA value 
from client W's account. Then, in block 428, the security 
server returns this value to foreign registry Z. In block 430, 
foreign registry Z requests the security server to return the 
value of foreign registry Z's foreign registry password 

15 propagate binding ERA. In block 432, the security server 
retrieves the value of the foreign registry password propa- 
gate binding ERA and then returns this value to foreign 
registry Z in block 434. 

Foreign registry Z then uses the value returned in step 428 

20 as routing information to locate the password synchroniza- 
tion server 106 as well as uses the value returned in step 434 
to specify the type of encryption that will be used to protect 
client W's password while it is "on the wire" or being 
transmitted between the password synchronization server 

25 and foreign registry Z that occurs in a later step. Further, 
according to block 436, the foreign registry Z then requests 
client W's password from the password synchronization 
server 106. In block 438, the password synchronization 
server 106 requests the security server 104 to return the 

30 value(s) client W's foreign registry ERA. In block 440, the 
security server 104 retrieves this value(s) from DCE registry 
102 and then returns the value(s) to the password synchro- 
nization server in block 442. 

In block 444, the password synchronization server 104 

35 inspects the contents of the return value(s) from block 442 
to determine if the requester, which is foreign registry Z, is 
identical to one of these values. This is an access control 
check. If the value is not identified, the password synchro- 
nization server returns a "error" message in block 446. 

40 Otherwise, in block 448, if the value is identified, the 
password synchronization server retrieves client W's pass- 
word from the password repository and decrypts it. Next, in 
block 450, the password synchronization server returns 
client W's password to foreign registry Z. 

45 FIG. 5 illustrates the password synchronization push 
function, a set of operations that automatically propagate 
password changes for selected users (accounts) to one or 
more foreign registries requiring this data. Without this 
function, a change to the password(s) for accounts of interest 

50 would result in a different password value for the account as 
defined in the DCE registry and the value as defined in the 
foreign registries. 

A description of the operations represented in FIG. 5 
follows and is further represented by the server in FIG. 3C, 

55 which illustrates only the elements of the DCE synchroni- 
zation and security system that are used in the synchroni- 
zation push operation. Beginning in Block 510, the client of 
Y first requests account creation or a password change for 
client Y's account. In Block 512, the security server 

60 retrieves the routing information contained in the password 
management binding ERA associated with client Y's 
account and uses it to locate to the password synchronization 
server. In Block 514, the security server then sends the clear 
text password and client Y identity to the password syn- 

65 chronization server. 

In Block 516, the password synchronization server then 
requests the DCE security server to provide ERA informa- 
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tion including the foreign registry ERA for client Y from the 
client Y account as well as all ERAs for the password 
synchronization server and foreign registry Z accounts. 

In Block 518, the security server retrieves the requested 
ERA information shown in DCE registry 102. In Block 520, 
the security server returns the ERA information to the 
password synchronization server, which then in Block 522 
validates that client Y foreign registry ERA content is also 
contained in the password synchronization server's foreign 
registry ERA. This is a "access control" feature in that it 
prevents one not authorized to decide which foreign regis- 
tries are authorized to receive password updates for client Y 
from causing changes to client Y's password to be propa- 
gated to unauthorized foreign registries. This is an effective 
access control check when, through the use of standard OSF 
DCE facilities, only a systems administrator or someone 
authorized to make such decisions is allowed to define the 
contents of the foreign registry ERA associated with the 
password synchronization server account. 

In Block 524, the password synchronization server uses 
the content of the client Y foreign registry ERA to request 
the foreign registry password prorogation binding ERA from 
the proper DCE registry account in DCE registry 102. For 
example, this is retrieved from the foreign registry Z 
account. 

Upon completion of locating the foreign registries for 
each server X-Z, the system, in Block 528 and through the 
password synchronization server returns a "complete" mes- 
sage to the security server 104. In Block 530, the security 
server 104 encrypts the password and then stores it in the 
client Y account. Afterwards, in Block 532, the security 
server returns a "complete" message to client Y. 

In Block 534, if the password propagate enable ERA 
indicates that it is "enabled," the password synchronization 
server, in block 536, sends the password to the foreign 
registry/server Z. Otherwise, the system returns. Next, in 
block 538, the foreign registry Z returns a synchronization 
complete status, failure status, or fails to respond if the 
network is down. If the signal is "complete," the system then 
returns; otherwise, the system proceeds to block 540. In 
block 540, if the password synchronization server receives 
failure status or times out awaiting a response, it re-queues 
this attempt for later retry after the time interval defined by 
the password propagate retry interval ERA has expired and 
then returns. 

Native OSF DCE provides for the support of multiple 
password strength servers. When the DCE registry receives 
a request to define or change the password for a given user, 
it uses the password_mgmt_binding ERA associated with 
the requesting user to locate what it believes is a password 
strength server, sends the user identity and plain text pass- 
word to that server, and then awaits a yes or no decision from 
the server. Design of the password synchronization function 
must not (and does not) require any change to the DCE 
security server, as this server may be implemented by 
various vendors on any platform supporting DCE. This 
invention cannot compel these vendors to make changes to 
their implementations of the security server and must there- 
fore preserve the operation of this interface between the 
security server and what it believes to be a password strength 
server. Design of the password synchronization server takes 
advantage of this interface, substituting itself in the position 
of a password strength server, while not perturbing the 
security server's belief it is a password strength server. 
While this is an effective approach to acquiring the plain-text 
password, thus enabling the password synchronization 
server to propagate it to foreign registries, it creates a 
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problem when one desires, for the same account, to both 
propagate password changes and perform password strength 
checking. This is so because there is but one password_ 
mgmt_binding ERA for a given account that is recognized 

5 by a native OSF Security server (and as just discussed, this 
invention cannot change security server behavior). 
Therefore, this one interface must support the functions of 
both password synchronization and password strength 
checking. Were it not necessary to preserve support for 

10 multiple password strength servers, each with its own 
customer-tailored set of composition rules, this constraint 
would not pose a significant problem. In this case, the 
password synchronization server 106 could, within its own 
processing steps, perform both propagation and strength 

15 checking. This not being the case, a different approach must 
be undertaken. Accordingly, in order to support customer- 
tailored password strength servers, password strength server 
110 is added to interface with the password synchronization 
server 106. 

20 With the addition of password strength server 110, the 
password synchronization server is able to route password 
change requests received from DCE registry 102 to the 
strength server 110. It then fields the password strength 
server's response, indicating password validity or invalidity, 

25 and returns the response to the DCE registry 102. Further, 
two new data items are required. The first is, for each user 
record in the DCE registry, a password strength ERA that 
must be created to contain the name of the password strength 
server that performs password composition checking for a 

30 given user. Also for each password strength server record in 
the DCE registry, a new data item, the secondary password 
management binding ERA is required. It contains informa- 
tion that allows the password synchronization server to 
locate the password strength server for a given user. In order 

35 to implement the use of the password strength server while 
also providing password synchronization among the foreign 
registries; the system implements the steps illustrated in 
FIG. 6. - 

FIG. 6 depicts the steps that extend password synchroni- 

40 zation to support password strength servers that may be 
customer-tailored according to a user's particular needs. 
Further, FIG. 3D illustrates only the elements of the DCE 
synchronization and security system utilized during strength 
checking. Note that, as in the native OSF implementation of 

45 password strength server support, only one password 
strength server can be associated with a given user, though 
different users may be configured to use different password 
strength servers. In block 610, client W 114 requests account 
creation or password change for the client W's account, 

so which is similar to the first step in FIG. 5, block 510. Next, 
in block 612, the security server 104 retrieves the routing 
information contained in the password management binding 
ERA associated with the client Y's account and uses it to 
locate password synchronization server 106, which again is 

55 similar to that of block 512 in FIG. 5. In block 614, the 
security server sends a clear text password and client Y 
identity to the password synchronization server 106. In 
block 616, the password synchronization server requests the 
security server to return the value of the password strength 

so ERA associated with the client Y's account and uses this 
value to identify the account for password strength server 
X110, The password synchronization server then requests in 
block 618 that the security server return the value of the 
secondary password management binding ERA associated 

65 with this account. 

The security server 104 retrieves the requested ERA 
values and then returns these values to the password syn- 
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chronization server in block 622. In block 624, the password 
synchronization server uses the information in the secondary 
password management binding as routing information to 
locate the password strength server X110 and requests this 
server perform its strength checking function. 

In block 626, the password strength server X110 performs 
the strength checking function and then returns either a 
complete signal or an error signal to the password synchro- 
nization server. Then, in block 628, the password synchro- 
nization server returns the complete or error message of 
block 626 to the security server 104. In block 632, if an 
"error" message is noted, the security server returns the error 
message to client W 114. If the complete message is sent, the 
security server encrypts the password, stores it in client W's 
account in block 630, and returns "complete" to the client. 

Password Synchronization Server Requirements 

The password synchronization function meets the follow- 
ing requirements. First, synchronization causes passwords 
changed by DCE users to be propagated as plain-text 
passwords to any other foreign registry configured to receive 
such changes. Propagation is immediate, with results saved 
for retry, as necessary, should communications with the 
foreign registries be broken. Retry propagation is subject to 
an administrator-controllable interval. This operation is 
referred to as "password synchronization push." 

Second, the password synchronization server enables 
password synchronization without modifications to the DCE 
Registry code, such that any vendor's DCE 1.1 Security 
Server can be used to support the password synchronization 
functions. 

Third, the password synchronization server preserves 
support for the password composition server (pwd__ 
strength) function provided by OSF DCE 1.1, and allows 
password strength checking to occur independently of 
whether a user's password is to be synchronized. 

Fourth, the password synchronization server supports 
plain-text password retrieval by a foreign registry upon 
foreign registry request. This operation is also called "pass- 
word synchronization pull." 

Fifth, the password synchronization server provides 
secure transmission of plain-text passwords parameters 
within the constraints imposed by client and server access to 
application data encryption functions. 

Sixth, the password synchronization server provides fault- 
tolerance. If the password synchronization server goes 
down, this prevents passwords from being updated in DCE 
accounts of interest to foreign registries and thus precludes 
an out-of-sync condition. To cover the case in which the 
password synchronization server goes down before having 
emptied its in-memory propagation queues, disk-mirroring 
of the queues is employed. If a foreign registry is down 
while password changes are made, the password synchro- 
nization server maintains the required state information to be 
able to attempt propagation when/if the foreign registry 
comes back on line. 

Seventh, in providing fault-tolerance (the sixth feature 
above), the password synchronization server recovers plain- 
text passwords from disk storage. It protects these pass- 
words while they are disk-resident by encrypting all plain- 
text password information into ciphertext format for disk 
storage. 

Although the above requirements must be fulfilled in a 
DCE environment as heretofore disclosed, these require- 
ments may be substantially modified, changed, or eliminated 
when implemented in a non-DCE server environment. In the 
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non-DCE case, it is recommended that the requirements be 
followed, but the skilled artisan may deviate from these 
conditions as necessary in order to tailor the system accord- 
ing to the needs and desires of the users. For example, 

5 although password encryption is useful, it need not be 
implemented if the overall system is protected from hackers 
or other unwelcome guests. 

The password synchronization server can be implemented 
in either a AIX or OS/2 platform, or any other type operating 

1Q system platform implementing DCE, such as, for example, 
other UNIX-type or MVS platforms. Further, the system 
may be configured on a single DCE machine. 

The absence of "over the wire encryption" protection of 
plain-text passwords between some nodes participating in 
password synchronization is accommodated. For example, 
lack of protection between two nodes can occur under either 
of the following conditions: 

a participating node is an incompatible DCE node which 
does not support DCE Data Encryption Standard (DES) data 

20 privacy; or 

a participating node is a DCE foreign registry that does 
support data privacy, and which is attempting a "pull" 
operation in a cell environment that includes at least one 
other DCE foreign registry that does not support data 

25 privacy. (I.e., all incompatible DCE foreign registries must 
be able to support data privacy if any of them is to be able 
to utilize such protection on password "pulls." This is so 
because compatible DCE foreign registries have access to an 
alternate data privacy encryption algorithm called Commcr- 

30 cial Data Masking Facility (CDMF) which can be used by 
the password synchronization function to provide "over the 
wire encryption" in the absence of access to DES data 
privacy. 

Of note, in the standard OSF implementation of password 
35 strength support, there is no "over the wire encryption" 
protection for plain-text passwords under the following 
circumstances: 

a) either the security server or the password strength 
server is unable to support data privacy (occurs on 

40 normal composition check). 

b) either a client or the password strength server is unable 
to support data privacy (occurs when the client attempts 
to request a password strength server-generated 
password). 

45 All customer-provided strength servers that may poten- 
tially cohabit in a cell containing a password synchroniza- 
tion server must supplement a check made in the OSF DCE 
sample code, whereby a strength check API is rejected if the 
caller is not the "dce-rgy" principal, to accept the API if the 

so caller is either "dce-rgy" or "pwsync." (These are the 
principals used by the security server and password syn- 
chronization servers when acting as a client to password 
strength servers.) 
It is not necessary to preserve the ability for a strength 

55 server to know the real client identity on a "generate 
password" request, whenever such requests are actually 
relayed to it via the password synchronization server. 

When a principal is configured for password 
synchronization, but not for password strength checking, the 

so minimum set of registry policy checks on password com- 
position (all blanks, at least one non-alphanumeric, mini- 
mum length) are not enforced. 

All foreign registries configured for support by the pass- 
word synchronization server must reside in the same DCE 

65 cell as the latter. 

All foreign registries should verify that the client identity 
initiating any "password push" RPC is that of the password 
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synchronization server (principal "pwsync"), to thwart any 
attacker's attempt to spoof the password synchronization 
server. 

The password synchronization server cannot be repli- 
cated. 5 

Overview of OSF DCE 1.1 Password Strength 
Checking 

A review of the password strength checking mechanism in 
OSF DCE 1.1 is given to provide a foundation for under- 10 
standing how password strength checking architecture can 
leveraged to implement password synchronization. 

By itself, the DCE security server provides a limited 
number of password composition rules. This includes mini- 
mum length, whether the password must contain at least one 15 
non- alphanumeric, and whether the password value can 
actually consist entirely of spaces. DCE 1.1 extends the 
capability of password composition checking by having the 
security server call out to a password strength-checking 
server whenever a password change request is received. This 20 
server also serves as a "password generator," and can be 
modified by customers to enforce any desired password 
composition rules. 

The security server checks are not enforced if a strength 
server exists for a user; however, the behavior of the default 25 
(OSF-provided) strength server is to enforce these same 
checks. Strength servers can be written to ignore enforce- 
ment of such specific checks. 

To support this new functionality, two new ERAs have 3Q 
been defined for password management in DCE 1.1: 
0 PWD_MGMT_B1NDING: This ERA attaches to a 
normal user principal and defines the strength server to 
be called by seed whenever an attempt is made to alter 
this user's password. This ERA is also used by a 3S 
"change password program" client and defines tbe 
server to invoke to obtain a generated password. This 
ERA is of the "binding" encoding type, containing this 
information: 

+ service principal name of strength server 40 
+ CDS namespace entry where server exports bindings 

or contains a string binding instead 
+ RPC authentication levels to be used in communi- 
cating with the server. 
An example of how this displays, using the dcecp 45 
convention, is: 

{pfwd_mgmL_binding{{dce pwd_strcngth pktprivacy secret 
name}/.:/fiubsy«/dce/pwd_mgmt/pwd__strength}} 

Password checking and password generation always take 50 
place in the same server, hence the need for only one ERA 
to define the location of this server. 

0 PWD„VAL_TYPE: This ERA is also attached to 
normal user principals. It can take one of four values: 
+ NONE (0): If the ERA value is zero, or the ERA 55 
doesn't exist for the user principal, it means no 
strength checking is done, except for minimal default 
rules enforced by seed itself. 
+ USER_SELECT (1): This means that password 
strength checking is performed by the server named 60 
in PWD_MGMT_BINDING whenever seed 
receives a request to create or alter an account 
password. 

+ USER_CAN_SELECT (2): This means that any 
client program that prompts for a new password 65 
should first display a generated password obtained 
from the strength server named by PWD_MGMT_ 
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BINDING. The user is free to type this or something 
else as the password choice. Upon receipt of a 
request to change an account password, seed always 
invokes the strength server check. If the user types 
the generated password, the strength server algo- 
rithm treats the new password as if the user con- 
cocted it, and can potentially reject it. OSF DCE 
should fix this anomalous behavior to be consistent 
with behavior in the next case -when a generated 
password is typed by the user. 
+ GENERATION_REQUIRED (3): This means that 
any client program that prompts for a new password 
should first display a generated password obtained 
from a strength server named by PWD_MGMT_ 
BINDING. The user is required to supply this pass- 
word as confirmation. Subsequently, seed invokes 
the strength server check, which will succeed only if 
the strength server sees, within a cache it maintains, 
that the password had recently been supplied to this 
client as a generated one. The generated password is 
not subject to any other composition rules that apply 
to user-concocted values. 
By necessity, a plain-text password is passed as either an 
input or an output parameter to the strength server. Rsec_ 
pwd_mgmt_str_chk passes plain text as an input. Rsec_ 
pwd_mgmt_gen_pwd returns plain-text as an output. Con- 
trol of the degree of protection on the password is 
accomplished by the security server's use of the protection 
level specified as one of tbe parameters in the authentication 
portion of the PWD_MGMT_BINDING ERA In the stan- 
dard OSF DCE implementation, this level can only be set to 
packet privacy or packet integrity, 

Part of the password synchronization implementation is a 
modification of OSF's DCE dcecp program and the corre- 
sponding underlying api to accept another protection level 
only supported by IBM DCE platforms, called "cdmf." 
Because the cdmf form of data privacy is freely exportable 
to foreign countries, generally including those that are 
unable to obtain a DES export license, IBM DCE support for 
the password strength and password synchronization func- 
tions provides a potential advantage over other vendors' 
implementations in that it will protect passwords on the wire 
in some circumstances where other implementations are 
unable to do so. 

Password Synchronization Overview 

The implementation of the password synchronization 
according to the present invention is now given. The system 
adds to or replaces the server that receives the callouts for 
password strength checking with a server that propagates 
passwords (a "push") to foreign registries instead. Before 
actually doing a "push," this server contacts the real strength 
server for password composition checking. In addition, this 
new password synchronization server fields requests to 
retrieve plain-text passwords (a "pull") from foreign regis- 
tries for a specified user. 

New and existing ERA definitions must be added or 
modified. The first two that follow are the existing ones, with 
a modified description of how they affect system behavior. 
The new ERAs then follow. See FIG. 3 for a pictorial 
representation of these ERAs and their associated principals. 

0 PWD_MGMT_BINDING: Same behavior as before 
when attached to a user principal, except that for a user for 
which password synchronization is relevant, the information 
within this ERA will point to 'pwysnc,' and not a real 
strength server. Users for which strength checking is 
relevant, but not synchronization, have the ERA set to point 
directly to a strength server. 
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An instance of this ERA also is attached to the 'pwsync' string value, namely the DCE server principal name of a 

principal itself. This serves as a convenient "template" that strength server. Thus, it denotes the strength server to be 

can be read by account administrative tools. I.e., the tool involved in any of this user's password changes, 

need not prompt for information necessary to have a new M can easil be se the PA SSWORD_STRENGTH 

user participate ui password synchronization; the data can be 5 vahle as a « k duri ord ch directi 

r rinciT as or on pwsy ^ ^ wor6 s y nc server t0 th " P f °P er ^ P rinci P a " 

prl A C mi7rw v»i T-vnc e ■ j u j from which to query the binding information as stored in the 

, P ^ D r^7? rPE: S ? rae , h meamn S s as . SECONDARY_PWD_MGMT BINDING era. 

above. Note that if 'pwsync* is the server pointed to by ^ „,* TT m r ^ ^^^^^ ~ ^^ T ^ n ^ . 

PWD_MGMT__BINDING, 'pwsync' does not re-read the 1fl 0 AVAILABLE_STRENGTH_SERVER: This multi- 

PWD_VAL_TYPE era. Rather, it relies on the value passed valucd ERA 15 storcd on thc P w sync principal only. It 

to it as a result of the strength check RPC to in turn pass on contains the names of all installed strength servers. Tools 

such requests to the real strength server. that need to know the names of all strength servers as 

FWD_VAL_TYPE must be set to 1 or greater if any candidates for attaching a single-valued PASSWORD_ 

password synchronization is to occur for a user principal. STRENGTH era on a new principal can obtain the list of 

PWD„VAL__TYPE should not exist, or have a value of 15 candidate servers by reading the value of AVAILABLE_ 

zero, for service principals. This is particularly important for STRENGTH_SERVER from the pwsync principal, 

the 'pwsync' service principal, for which a "template" value The PWSYNC facility also inspects AVAILABLE_ 

of PWD„MGMT_BINDING exists. STRENGTH_SERVER contents as attached to the 

0 FO REIGN_RE GISTRY_PW_PROP_JBI ND IN G : "pwsync" principal, as a validity check on the legal values 

This ERA is associated with the principal object for foreign 20 of PASSWORD_STRENGTH ERAs attached to user prin- 

registries. It contains binding and authentication information cipals. Hence, the presence of AVAILABLE_ 

for use by the password sync server in propagating pass- STRENGTH_SERVER is mandatory, not optional 

words to the foreign registry on a "push." 0 PLAINTEXT_PASSWORD: This ERA is a query 

0 FOREIGN_REGISTRY: This multi-valued ERA is trigger associated with a normal user's principal object, 
associated with a normal user's principal object. It contains Foreign registries will "pull" a recoverable plain-text pass- 
one or more character strings, identifying the DCE server word when needed by querying the value of this ERA. The 
principal name(s) of a foreign registry(s). It thus represents request will be rerouted from seed to the password sync 
a registry(s) to which changes in this user's password should server, by virtue of the query trigger stored in the schema 
be propagated. It is also used in a "pull" operation by the 3Q definition having binding and authentication information for 
password synchronization service as an access control pwsync. There is no need to alter the schema permissions to 
mechanism. This is accomplished by insuring that the DCE restrict tightly who can read this sensitive ERA, because 
identity of the "pulling" program is one of the entries found pwsync itself makes the validity check as to who can query 
in the FOREIGN__REGISTRY ERA attached to the user such sensitive information as a function of the values of the 
principal for which the request is made. 35 . FOREIGN_REGISTRY eras that attach to a user's princi- 

As can easily be seen, the FOREIGN_REGISTRY value pal. If the plain-text password is not known by pwsync, a 

serves as a "key" during a password propagation, directing NULL string will be returned as the password, 

the DCE software to the proper service principal from which o PW_PROPAGATE__£NABLE: This ERA is attached 

to query the binding information as stored in the to the pwsync principal and contains a boolean true/false 

FOREIGN_REGISTRY__PW JROP_BINDING era. ^ indication of whether password propagation is enabled. 

This multi-valued ERA is also stored on the pwsync When disabled, propagation via "push" is disabled, but 

principal, but its meaning is different than when attached to foreign registries may still "pull" passwords, 

normal principals. It contains the values of all installed o PW_PROPAGATE_RETRY_JNTERVAL: This ERA 

foreign registries. Tools that need to know the names of all ^ attached to the pwsync principal and contains a signed 32 

foreign registries as candidates for attaching FOREIGN_ 45 bit integer value representing the interval (in seconds) at 

REGISTRY ERAs on a new principal can obtain the can- wn i cn passwords are propagated to foreign registries if their 

didate list by reading the value of FOREIGN__REGISTRY initial propagation had failed. A value of zero is illegal, and 

from the pwsync principal. effectively inhibits retry propagation. The value of this ERA 

The PWSYNC facility also inspects FOREIGN_ is moot if PW__PROPAGATE_ENABLE is marked to 

REGISTRY contents as attached to the "pwsync" principal, 50 disable propagation altogether, 
as an access control check on the legal values of 

FOREIGN_REGISTRY eras attached to user principals. Password Synchronization Implementation 

Hence, the presence of FOREIGN_REGISTRY is The basic structure of the password synchronization 

mandatory, not optional. server consists of a main routine that performs setup tasks 

0 SECONDARY_PWD_MGMT_BINDING: This ss typical of DCE servers and then 'listens' for requests, a key 

ERA is associated with the principal object for a password management thread, an identity refresh thread, a Pull data 

strength server. It contains binding and authentication infor- base pruning thread, and routines for handling the RPC 

mation for use by the password synchronization server in initiated as the result of a foreign registry reading the 

relaying requests for password generation and password plain text_password ERA associated with a given user, and 

checking. Since pwsync is the direct recipient of such 60 the rsec_pwd_mgmt_str_chk RPC from the security 

requests because of the PWD_MGMT_BINDING server. The latter RPC, though, as implemented in pwsync is 

contents, a "secondary" ERA is needed so that pwsync can now basically a way-station. Rather than perform the actual 

route such requests to an actual genera to r/checker. Such core functionality itself, it now forwards the request to the 

callouts to strength servers occur before any attempt to password strength server in effect for the subject principal, 

propagate a new password to foreign registries. 65 New functionality consists primarily of the functions that 

0 PASSWORD_STRENGTH: This ERA is associated support "push" and "pull" operations requested by foreign 

with a normal user's principal object. It contains a character registries wishing to maintain password synchronization 
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with the DCE registry. rsec_p wd_mgmt__str__chk serves as 
the gateway to this new functionality, as it provides the 
means by which pwsync can get its hands on the new 
password data. 

"Push" refers to the propagation of a user's plain-text 
DCE password to interested and authorized foreign registry 
servers whenever the password is changed in DCE. Such 
"pushes" do not occur as an integral part of the rsec_pwd_ 
mgmt str_chk processing, as one might initially suspect. 
Delaying the return to seed is undesirable from a human 
factors perspective. Thus, the data is instead stored in an 
in-memory queue for later processing by separate propaga- 
tion threads. (The first propagation attempt is immediate, 
with retries taking place at administrator-specified 
intervals.) Disk mirroring is used to prevent loss of data in 
the event of unexpected program termination. Such loss 
would otherwise result in out-of-sync conditions between 
the DCE and foreign registries. Note that when the password 
synchronization server's propagation thread performs a 
"push" operation, it is acting as a client of the foreign 
registry exporting the relevant "push" server interface 
(rsec_pwd__propagate). 

"Pull" refers to the password synchronization server's 
role as trigger server with reference to the PLAINTEXT_ 
PASSWORD extended registry attribute. Foreign 
registries' queries of the value of this attribute are routed by 
native OSF DCE function to pwsync for retrieval of the 
associated password. To accommodate this, pwsync exports 
the sec_attr_trig_query interface. Having plain-text pass- 
words available "on demand" means that pwsync must 
maintain a permanent record of user names and their asso- 
ciated passwords. Although it is a given that in light of the 
sensitive functions it performs pwsync should reside on a 
highly secure machine, it is also clear that the passwords in 
this database must be afforded extra protection. Such pro- 
tection is modeled after the DCE Security Server's master- 
key encryption of sensitive Registry data. (The same pro- 
tection is afforded to passwords in the "push" database, 
although it is less crucial because the data there is expected 
to be short-lived.) 

The Password Synchronization server consists of a single 
process with a main thread and five auxiliary threads. Flow 
diagrams detailing the processing steps for two of these 
threads and for the rsec_pwd_mgmt_str__chk RPC inter- 
face servicing calls from the security server follow. 

1) Main Thread: Performs initialization functions 
required by all such DCE application servers, e.g., 
registers bindings and interfaces in the Cell Directory 
namespace, creates all auxiliary threads, "listens" on 
RPC interfaces to service calls from the security server 
and from foreign registry clients attempting to "pull" a 
password for a specific account. 

2) Password Synchronization Server Identity Refresh 
Thread: Reestablishes this server's DCE identity by 
"logging in" as the server on a periodic basis, (standard 
practice and method for all DCE application servers). 

3) Password Synchronization Server Key Refresh Thread: 
Changes the account password for this server on a 
periodic basis, which is well known in the practice and 
method for all DCE application servers. 

4) Password Synchronization Server Pull RPC and Pull 
Data Base Pruning Thread: At initialization, the pass- 
word synchronization server main thread initializes the 
Memory Pull Data Base from the Disk Pull Data Base 
and eliminates all entries for each user present that are 
superseded by another entry for the same user. When a 
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Pull request is received on the RPC upon which the 
main thread is listening, the memory data base is 
searched for an entry for the requested user. If found, 
the contents of the foreign__registry ERAs associated 

5 with both the password synchronization server's and 
requested user's account are inspected to determine if 
the requesting foreign registry is defined in these 
ERAs. If so, the password for the requested user is 
returned on this RPC. If the password is not found or 

10 the inspection fails, an error is returned. The Pull Data 
Base Pruning thread operates on a timer to periodically 
prune the disk pull data base of all entries for each user 
present that are superseded by another entry for the 
same user. 

15 5) Password Synchronization Server RPC from Security 
Server: When the main thread receives a call from the 
security server via this RPC, the processing steps 
depicted in FIG. 7 are performed, 

6) Password Synchronization Server Propagation Queue 
20 Thread: When the password synchronization server 

sets Signal "P" (shown in FIG. 7), this thread is 
awakened to perform the processing steps depicted in 
FIG. 8. 

7) Password Synchronization Server Retry Queue Thread: 
25 When the Propagation Queue thread sets Signal "R" 

(shown in FIG. 8), this thread is awakened to perform 
the processing steps depicted in FIG. 9. 
FIG. 7 depicts a flow chart of user password processing 
from the security server. First, in block 710, the password 

30 synchronization server receives the user ID and password 
from the security server. Then, in block 712, the synchro- 
nization server determines if the password strength ERA is 
present for the user and if so proceeds to block 714; 
otherwise, the security synchronization server proceeds to 

35 block 720 described below. In block 714, the synchroniza- 
tion server uses the password strength ERA to identify the 
appropriate password strength server associated with the 
user and its account and then reads its secondary password 
management binding ERA. After completing block 714, the 

40 synchronization server proceeds to block 716 where the 
password strength server account and secondary manage- 
ment binding ERA are used to locate the password strength 
server and call the strength server with the user 
ID/password. 

45 In block 718, the password strength server returns a 
message of whether its composition check was successful. If 
so, if the system proceeds to block 720; otherwise, the 
system proceeds to block 732 further described below. In 
block 720, the systems add or replaces the entry in the 

50 memory pull database and appends the entry to the disk pull 
database 112. The memory pull database is illustrated in 
block 722, while the disk pull database is illustrated in block 
724. Next, in block 726, the system determines whether an 
error has occurred and if so, it proceeds to block 732; 

55 otherwise, if no error has occurred, the system proceeds to 
block 728 where the system sets the status message as being 
a "success." If an error has occurred or if the password 
strength server composition check failed, then, in block 732, 
the system sets the status message as "failure." If a failure 

60 has occurred, the system then proceeds to block 742, 
described below. 

In block 730, a password strength server determines if a 
propagation has been enabled as a function of the value of 
the pw_propagate_enable ERA. If the propagation has 

65 been enabled, the system proceeds to block 734, otherwise, 
in the system proceeds to block 742 described below. In 
block 734, the strength server stores the entry in memory in 
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the propagation queue and also in the disk propagation In block 920, the system processes the first or next 

queue represented by blocks 736 and 738, respectively. The identified entry in queue 834 and then inspects this entry in 

system then proceeds to block 740 where the strength server block 922 to determine if this foreign registry marked as 

sets the signal "P" for propagation queue thread described "NOT NOW COMMUNICATING ON THE RETRY 

above. Afterwards, and if the propagation enable had not 5 QUEUE" If it is not so marked, the system proceeds to block 

been set in block 730, the system, in block 742, returns the 924; otherwise, if it is marked, the system proceeds to block 

status to the security server. 932 described below. In block 924, the system propagates 

The password synchronization server propagation queue the user ID/password to this selected foreign registry. Then, 

thread operates according to the steps illustrated in FIG. 8, in block 926, the system determines if a successful propa- 

The password synchronization server, in block 810, initial- 10 gation has occurred and if so proceeds to block 930 

ized a memory propagation queue from the disk propagation described below; otherwise, the system proceeds to block 

queue, which are block 736 and 738, respectively, as 928. In block 928, the system marks if this foreign registry 

described in FIG. 7. Next, in block 812, the system waits for on the retry queue as "NOT NOW COMMUNICATING?" 

a wake-up signal from the signal "P" from FIG. 7, block 740. and proceeds to block 932. 

In block 816, the system then determines if an entry has been 15 In block 930, this foreign registry's entry on the propa- 

made in the memory propagation queue 736 and if not gation queue (FIG. 8, 736) is inspected to see if it is marked 

returns to block 812; otherwise, the system proceeds to as "NOT NOW COMMUNICATING" If so, it is reset; if 

block 818 where the synchronization server processes the not, it is left as is and processing proceeds to block 932. 

first or next entry in queue 736. Next, in block 820, the In block 932, the synchronization server determines if any 

system retrieves a list of foreign registries from the user's 20 more entries are present in the memory entry queue 834 and 

foreign registry ERA found in the user's account. Once the if so, returns to block 920 described above and completes the 

list has been retrieved, the system, in block 822, validates sequence thereafter; otherwise, if there are no other entries 

the presence of the first or next foreign registry against the in the memory entry queue 834, the system proceeds to 

fist of foreign registries found in the foreign registry ERA for block 934. In block 934, the system resets all foreign 

the password synchronization server. Once the validation 25 registries to "NOW COMMUNICATING" on the retry 

has been completed, the particular foreign registry on the queue 834. Next, in block 936, the system reconstructs the 

propagation queue 736 is then inspected to see if it is disk retry queue from the memory retry queue 836 and 834, 

presently marked as "NOW COMMUNICATING" and if respectively. Then, in block 938, the system sets the signal 

not, the system proceeds to block 840 described below; "R" based on the password propagation retry interval ERA 

otherwise, the system proceeds to block 826. 30 previously described. Once the signal has been sent to "R," 

In block 826, the system propagates the user ID/password the system then returns to block 916 for the next retry cycle, 
to the requesting foreign registry of block 824 and then in 

block 828, determines whether the propagation has been Plain-Text Password- Protection 

successful and if so proceeds to block 838: otherwise, if the ^ r , . . .. 

a 1 *u 4. * . li * Operation ot the password security synchronization 

propagation is unsuccessful, the system proceeds to block 35 /mi ^ VXT o Uft/ ■ , i nn^ *l * i • . . 

oi« t li 1 £>i a il , i , 1L i c (PWSYNC) 106 invo Ives several RPCs that pass a plain-text 

830. In block 830, the system marks at the particular foreign v , ' » • . , 

J ' . «xt^ \t»-\it j password as a parameter. It is important that these passwords 

registry on the propagation queue as NOT NOW COM- f . , , r , , « r . „ 4 r , it _ . 

* * t tntt/*" 1 a TTMr *» tt. * *L a * ui i oii De protected when passed "over the wire, to prevent their 

MUNICATING " The system then proceeds to block 832 r , r . , r 

, . J , , c . exposure to unauthorized parties, 

where the system stores the user s ID, password, foreign r r 

registry ID/communication status in the memory retry queue 40 ^ m are several scenarios to consider, involving whether 
834 and the disk retry queue 836. one * ninning in a USA or international environment, or 
In block 838, if the foreign registry in not now commu- whether one is operating with compatible DCE servers or 
mealing or the propagation of block 828 had been sorae other vendor's servers. Before thinking about such 
successful, the system determines whether there are addi- scenarios, it is helpful to understand the nature of the RPCs 
tional foreign registries for this particular user ID being 45 squiring protection, and the controls that affect the level of 
processed and if so returns to block 822 et seq. Otherwise, securitv ^ when ""^g them ' ™ ese "controls" are the 
if no more foreign registries are associated with this user ID, DCE registry entities known as "binding authentication 
the system proceeds to block 849 where the system deter- information" as stored in some ERA instances, and in one 
mines whether there are any more entries in memory propa- case slored 35 9 uer y tri Sg er information directly within a 
gation queue 736. If there are more entries in the memory 50 schema entrv ' ™* level of protection used between any two 
propagation queue, the system returns to block 818 and the programs that pass a plain-text password as a parameter is 
process starts over again for the next entry in the propagation dictated by these controls, whose format follows this con- 
queue; otherwise, the system proceeds to block 842, where venUon when usm S lhe dcec P program provided by OSF 
the synchronization server deletes all entries in memory DCE ll- The well-known "pwd„mgml_binding" era is 
propagation queue 736 and disk propagation queue 738. 55 used as an illation here: 

Afterwards, the system then returns to block 812, awaiting . , , , . ,. . , , , t t . vvvvvwv 

' b {pwd_mgmL_binding{{dcc pwd__Mrength XXXXXXXX secret 

the settling ot Signal V . name}/.:/subsys/dce/pwd_mgmt/pwd_6trength}} 

All propagation retries are processed according to the 

method depicted in FIG. 9. FIG. 9 depicts a flow chart of the where the "control" XXXXXXXX can be set to either 

password synchronization server retry queue thread accord- so "pktprivacy," "cdmf," or "pktinteg," according to whether 

ing to the present invention. First, in block 910, the pass- the programs are on compatible platforms and whether the 

word synchronization server initializes the memory retry platforms support data privacy. 

queue from the disk retry queue at blocks 834 and 836, As can be seen, this ERA also contains other necessary 

respectively. Next, the system proceeds to block 918 where information, such as the service principal name, the CDS 

the system determines if there are any entries in the memory 65 namespace location where the service has exported its 

retry queue 834 and if so, proceeds to block 920; otherwise, binding, and a specification to authenticate in the old Ker- 

the system proceeds to block 938 described below. beros fashion, by "name." 
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Table 1 summarizes all of the information needed to 
understand how such controls are used, how they are set, and 
whether they address all situations involving client/server 
communication in the password synchronization environ- 
ment. 

There are seven distinct points where programs will issue 
an RPC that should be considered for over-the-wire protec- 
tion of plain-text passwords. This design is concerned with 
six of them. (One point of not much concern is the initial 
user request to change a password via sec_rgy_acct_ 
passwd, in which case DCE already prompts for a "caller 
key" to encrypt the password over the wire.) The chart 
identifies the pertinent information for each of these RPCs, 
The first three are part of a "push," the fourth one is part of 
a "pull," and the last two deal with the password generation 
capability. 
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pwsync principal itself. These customer or vendor- written 
administrative tools, which use well-known OSF DCE func- 
tions to accomplish their tasks, can simply read the ERA 
information attached to "pwsync" principal, allowing it to 
display the information for administrative selection when- 
ever a new user principal is being defined. 

The "PROT LVL UNIQ?" column of the chart indicates 
whether the particular protection level is assigned to a single 
"client/server" pair, or whether it can be shared between 
multiple pairs. For example, the second and third items have 
unique and unambiguous protection level controls because 
there is a separate ERA instance for each and every foreign 
registry or password strength server communicated with by 
pwsync. Thus, if some foreign registries require different 
protection levels, these would be accommodated because 
there are separate ERAs to reflect those differences, speci- 
fied during the installation of each foreign registry. 



TABLE 1 











ERA 










PROTECTION LEVEL 


CREATED, 


PROT. 




RECEIVE 




CONTROLLED BY BINDING 


PROTECT LVL 


LVL 


SENDER 


R 


RPC NAME 


INFO STORED IN 


SET BY 


UNIQ? 


seed 


pwsync 


resec_pwd_ 


PWD_MGMT_BINDING era 


configuration 


NO 






mgmt_sti_ 


of use principal 


"pw sync" 








chk 




option 




pwsync 


customer 


rsec_pwd_ 


SECONDARY_PWD_MGMT_ 


configuration 


YES 


strength 


mgmt_str 


BINDING era of the 


"strength" 






server 


_chk 


strength server prin 


option 




pwsync 


foreign 


rsec_pwd„ 


FOREI GN_REG ISTRY_P W_ 


configuration 


YES 


registry 


propagate 


PROP_BINDING era of 


"foreign 










the foreign registry principal 


registry" 












option 




foreign 


pwsync 


scc_attr_trig_ 


query trigger info 


configuration 


NO 


registry 




query via 


of PLAINTEXT ^PASSWORD 


"pwsync" 








sec_rgy_attr_ 


schema entry 


option 








lookup_by_* 








client 


pwsync 


sec_pwd_ 


PWD _3IGMT BINDING era 


rgy update 


NO 


machine 




mgmt_gen_ 


of user principal 


tool: acct 








pwd 




add/change 




pwsync 


customer 


sec_pwd__ 


SECONDARY_PWD _Jv1GMT__ 


configuration 


YES 


strength 


mgmt_gen_ 


BINDING era on the 


"strength" 






server 


pwd 


strength server prin 


option 





Protection levels for those ERAs that only attach to 
service principals are reasonably easy to administer because 
they only have to be specified once, during the installation 45 
of either pwsync, a strength server, or a foreign registry 
server. This is true whether the installation package is from 
the same or a different vendor. All of these installations 
involve the creation of service principals, and attachment of 
the ERA instance to those principals. 

Other ERA values, however, specifically those that are 50 
attached to regular user principals, are administered with a 
little more difficulty because the contents of these ERAs are 
dependent upon information related to foreign registries and 
to password strength servers. Without the aid of an admin- 
istrative tool, e.g., GUI, that "remembers" or has access to 55 
the pertinent information associated with these servers when 
they were installed, and that has "canned" information 
defining what ERAs need to be associated with these 
principals, administrators would be forced to create manu- 
ally these ERA instances on newly created principals, which 60 
can be a cumbersome, error-prone task. The relevant ERAs 
include the well-known PWD_MGMT_BItSTDING, and the 
new "printstring" ERAs known as FOREIGN_REGISTRY 
and PASSWORD__STRENGTH . 

The method by which foreign registries and customer 65 
strength servers shall communicate such information to 
administrative tools is to attach the information onto the 



A value of "no" in this column indicates that a specified 
protection level is not unique across all client/server com- 
binations. For example, item 4 has the problem that all 
"pulls" from foreign registries are subject to the authenti- 
cation information stored in one single query trigger item. 
There is only one definition of a schema, so the 
PLAIiVTEXT_PASSWORD definition applies to all foreign 
registries, precluding the ability for these registries to use 
different protection levels. 

Another example is the combination of items 1 and 5, 
where the same ERA attached to a user principal serves to 
denote the protection level between two distinctly different 
operations. This precludes the ability to select a different 
protection level to be used between pwsync and seed on a 
strength API, and between pwsync and a client machine for 
a password generation API request. 

For the above "no" cases, foreign registries and clients 
from different vendors are typically required to live with the 
"lowest common denominator," which may result in the 
absence of plain-text password protection for these cases. 
For these same cases where foreign registries and clients 
from the same or a compatible vendor are involved, modi- 
fications to two APIs should be made to take advantage of 
the maximum degree of protection afforded by a particular 
client/server pair: 

1) The sec_rgy_attr_lookup_* APIs modified to rec- 
ognize the "PLAINTEXT ^PASSWORD" ERA name as a 
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special case. The "authentication information" portion of the 
query trigger will be discarded, keeping the principal and 
CDS information necessary to communicate with pwsync. 
The proper authentication information is obtained by issuing 
a callback to seed to query the value of FOREIGN_ 
REGISTRY_PW_PROP_BINDING for this particular 
foreign registry. This authentication data is unique per 
foreign registry, as opposed to the auth data stored in the 
query trigger. It includes the protect level to be used in 
protecting data "on the wire." 

Other ERAs having defined query triggers are not affected 
by this change. They continue to use all of the information 
supplied in the query trigger, including parameters control- 
ling the various authentication levels. 

DCE foreign registries from differing, incompatible 
vendors, on the other hand, are all forced to use the same 
protect level, that which is defined in the query trigger. This 
must be the "lowest common denominator;" i.e., if one 
incompatible foreign registry can only support packet 
integrity, then all incompatible foreign registries must oper- 
ate under that constraint. 

2) The appropriate value for the protect level stored in any 
given user's PWD_MGMT_BINDING shall be con- 
sidered to be the maximum level allowed between seed 
and pwsync when issuing the strength API. However, 
this may be too high for use between a normal client 
and pwsync on a "generate password" request. Hence, 
the IBM version of sec_pwd__mgmt_gen__pwd insti- 
tutes "application retry logic." If the initial value fails 
because of the inability to support "pktprivacy," the 
client logic will retry using "cdmf." If that fails, it will 
use "pktinteg." While this scheme is effective for IBM 
DCE clients, it may not be implemented in non-IBM 
DCE clients, as the CDMF algorithm is presently not 
exportable to foreign countries by any company other 
than IBM. 

In the situation where a non-compatible DCE client 
machine is incapable of supporting the protection level 
specified in PWD_MGMT_BINDING, any attempt by this 
client to request "password generation" will fail. Options 
available to the administrator to rectify this situation include 
eliminating the requirement that a given principal who 
wishes to change his password from this machine be pro- 
vided with a password synchronization server-generated 
password, or, downgrade the protection level specified in 
PWD_MGMT_BINDING for this principal to "packet 
integrity." The latter option preserves desired functionality 
at the expense of exposing the plain-text password "over the 
wire" for this principal. 

Schema definitions for the new ERAs are required for this 
password synchronization implementation. The value of the 
"reserved" flag is set TRUE for all of these ERAs, since once 
pwsync has been installed, "accidental" erasure of schema 
definitions should be avoided. Administrators can set the 
reserved flag to FALSE and then delete the schema defini- 
tions if they so desire. 

There is only one new RPC, in support of the "push" 
protocol: 



FUNCTION PROTOTYPE: 

void isec_pwd_propagate ( 
[in] handle_t h, 

[in] sec_rgy__name__t principal, 
[in] char * password, 

[in] sec_timeval_sec_t pwd change_time, 

[out] error_status_t • status 

); 



The RPC propagates passwords to foreign registries. All 
foreign registries must reside in the same cell as the pass- 
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word synchronization server. The username and time of 
DCE registry update are also provided. If the foreign registry 
wishes to discard the information and not be informed of the 
very same password change event in a later propagation 

5 cycle, it should return successful status. If for any reason it 
cannot handle the notification at the present time, but would 
like for the password sync server to send the event in a later 
propagation cycle, then an unsuccessful status, of any kind, 
should be returned. 

1Q Except in the case of access to the "password pull" 
database, all contention for internal resources is always 
"mutually exclusive." There is no advantage in taking on the 
extra overhead of locking macros for such cases. Hence, 
direct calls to DCE pthread's "mutex" APIs are used when 
resources cannot withstand shared access of any kind. In 

15 essence, then, mutex acquisition is equivalent to obtaining a 
"write lock " with the mutex holder blocking all others 
trying to obtain the mutex; except that the added overhead 
of locking logic on top of the mutex calls is avoided. 
"Mutex" is an OSF DCE pthread component that is equiva- 

20 lent to a "lock" and is well know to those skilled in the art. 
In the case of the password pull database, the server takes 
on the added overhead of locking macros and software, 
patterned after the DCE security server (seed) and adapted 
for the password synchronization server's use. Use of the 

25 locking paradigm is deemed necessary so that when the pull 
database is periodically pruned of excess entries and sorted, 
requests to "pull" a password are not blocked; yet requests 
to change a password in the pull database are blocked. This 
cannot be easily accomplished by direct calls to pthread 

3Q mutex routines. Id fact, that is what the seed locking 
interfaces were designed to do: to provide a slightly more 
complicated interface to the calling threads; have that inter- 
face maintain state information as to what type of lock is 
currently held, and by how many threads; and to use that 
information to determine if pthread's mutex library should 

35 be invoked to truly block any calling threads. 

As indicated above, aspects of this invention pertain to 
specific "method functions" implementable on computer 
systems. In an alternate embodiment, the invention may be 
implemented as a computer program product for use with a 

40 computer system. Those skilled in the art should readily 
appreciate that programs defining the functions of the 
present invention can be delivered to a computer in many 
forms, which include, but are not limited to: (a) information 
permanently stored on non -writ able storage media (e.g. read 

45 only memory devices within a computer such as ROM or 
CD-ROM disks readable by a computer I/O attachment); (b) 
information alterably stored on writable storage media (e.g. 
floppy disks and hard drives); or (c) information conveyed 
to a computer through communication media, such as a 

50 network, and telephone networks, via modem. It should be 
understood, therefore, that such media, when carrying com- 
puter readable instructions that direct the method functions 
of the present invention, represent alternate embodiments of 
the present invention. 

ss While the invention has been particularly shown and 
described with reference to a preferred embodiment, it will 
be understood by those skilled in the art that various changes 
in form and detail may be made therein without departing 
from the spirit and scope of the invention. 

60 What is claimed is: 

1. A network system server that provides password syn- 
chronization between a main data store and a plurality of 
secondary data stores, said network system server compris- 
ing: 

65 a security server coupled to said main data store, said 
security server controlling communication with said 
main data store; 
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a plurality of clients coupled to said security server, said computer usable code means for retrieving said clear-text 

plurality of clients only accessing said main data store password by said one of said plurality of secondary 

through said security server, each of said plurality of data stores. 

clients maintaining a unique, modifiable password; U. A computer program product according to claim 10, 

a password synchronization server coupled to said secu- 5 and further comprising: 

rity server and to said plurality of secondary data computer usable code means for encrypting said clear-text 

stores i and . password; and 

a password repository coupled to said password synchro- t . . , . t . . . ■ 

nization serVer, said password repository storing pass- com P uter ™ Mt cod f means *> r stonn e said encr yP ted 

words of said plurality of clients, said passwords in said 10 clear-text password in an information account, 

password repository being retrievable by said plurality 12 - A computer program product according to claim 9, 

of secondary data stores via said password synchroni- and fu rtaer comprising: 

zation server so that each client is able to maintain a computer usable code means for binding each of said 

single, unique password for all of said plurality of plurality of secondary data stores with each of said 

secondary data stores. 1$ plurality of clients. 

2. A network system server according to claim 1, and 13. A computer program product according to claim 9, 
further comprising said main data store, said main data store and further comprising: 

including an information account for each of said plurality computer usable code means for performing a propaga- 

of clients, each information account including a password of tion retry in the event of an outage of a temporary 

a corresponding client. 2Q foreign registry or password synchronization server. 

3. A network system server according to claim 2, said 14. a computer program product according to claim 9, 
security server providing a clear-text password to said sa id password retrieval being instigated by at least one of 
password synchronization server for retrieval by said one of sa jd plurality of secondary data stores regardless of the 
said plurality of secondary data stores. current password status of said plurality of secondary data 

4. A network system server according to claim 3, said ^ stores. 

security server including means for encrypting said clear- 15, a computer program product according to claim 9, 

text password for storage in said information account. anc i further comprising: 

5 A network system server according to claim 1, and compu ter usable code means for checking that each client 

further composing said main data store, said main data store ma intains a password having a composition consistent 

including an information account for said password syn- 3Q with a set of mlefi fof said main data stQre 

chrornzation server that binds each of said plurality of 16 A CQm m duct accordi to claim 9j 

secondary data stores with each of said plurality of clients said ter ^ means for retrieving comprisirjg: 

6. A network system server according to claim 1. and , , , . . 
further comprising said main data store, said main data store com P uler ^ ble mea t ns ' «?°n"ve ,0 recei P l ° f a 
including an information account for each of said plurality „ "^f for / P^word of a particular chen. among said 
of secondary data stores. 35 P 1 ™ 1 "? of d^nts said request being transmitted by a 

7. A network system server according to claim 1, further m P ata ! »°«*ted with one of said plurality of sec 

. • ' ondary data stores, for determining if said requestor is 

, - i . A j i permitted access to said password of said particular 

a temporary memory data store coupled to said password client* and 

synchronization server and containing information sup- aq ' 

porting a propagation retry, said temporary memory computer usable code means, responsive to a determina- 

data store allowing said password synchronization tioD said requestor is permitted access to said 

server to perform a propagation retry in the event of an password, for transmitting said password to said 

outage of a temporary foreign registry or said password requestor for storage in said one of said plurality of 

synchronization server. 45 secondary data stores. 

8. A network system server according to claim 1, at least 11 • A computer program product according to claim 16, 
one of said plurality of secondary data stores accessing wherein: 

passwords in said password repository regardless of the said computer usable code means for transmitting corn- 
current password status of said plurality of secondary data prises the computer usable code means for transmitting 
stores. 5 q s ^d password to said requestor in encrypted form; and 

9. A computer program product that provides password said computer program product further comprises corn- 
synchronization between a main data store and a plurality of puter usable code means for transmitting, to said 
secondary data stores, said computer program product com- requester, an indication of a type of encryption utilized 
prising: to encrypt said password. 

computer usable code means, for maintaining a unique, 55 18. A method of providing password synchronization 

modifiable password for each of a plurality of clients between a main data store and a plurality of secondary data 

coupled to said main data store; stores, said method comprising: 

computer usable code means for retrieving a password for maintaining a unique, modifiable password for each of a 
one of said plurality of secondary data stores so that plurality of clients coupled to said main data store; and 
each client among said plurality of clients is able to so retrieving a password for one of said plurality of second- 
maintain a single, unique password for said main data ary data stores so that each client among said plurality 
store and all of said plurality of secondary data stores, of clients is able to maintain a single, unique password 
such that password synchronization is maintained. for said main data store and all of said plurality of 

10. A computer program product according to claim 9, secondary data stores, such that password synchroni- 
and further comprising: es zation is maintained. 

computer usable code means for providing a clear-text 19. A method according to claim 18, and further corn- 
password based on said user's unique password; and prising the step of: 
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providing a clear-text password for retrieval by said one 
of said plurality of secondary data stores, 

20. A method according to claim 19, and further com- 
prising the step of: 

encrypting said clear-text password; and 5 
storing said encrypted clear-text password in an informa- 
tion account. 

21. A method according to claim 18, and further com- 
prising the step of: 

binding each of said plurality of secondary data stores 
with each of said plurality of clients. 

22. A method according to claim 17, and further com- 
prising the step of: 

performing a propagation retry in response to an outage of 15 
a temporary foreign registry or password synchroniza- 
tion server. 

23; A method according to claim 18, said password 
retrieval being instigated by at least one of said plurality of 
secondary data stores regardless of the current password 2 o 
status of said plurality of secondary data stores. 

24. A method according to claim 18, and further com- 
prising: 
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checking that each client maintains a password having a 
composition consistent with a set of rules selected for 
said main data store. 

25. A method according to claim 18, said retrieving step 
comprising the steps of: 

in response to receipt of a request for a password of a 
particular client among said plurality of clients, said 
request being transmitted by a requestor associated 
with one of said plurality of secondary data stores, 
determining if said requestor is permitted access to said 
password of said particular client; and 

in response to a determination that said requester is 
permitted access to said password, transmitting said 
password to said requestor for storage in said one of 
said plurality of secondary data stores. 

26. A method according to claim 25, wherein: said trans- 
mitting step comprises the step of transmitting said pass- 
word to said. requestor in encrypted form; and 

said method further comprises the step of transmitting, to 
said requestor, an indication of a type of encryption 
utilized to encrypt said password. 

***** 
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